Channel based privilege support direction from Redfish

I am trying to expand the question here...

Redfish's basic model is: an agent uses HTTPS to authenticate to a Redfish API server which then maps the identified username (aka account name) to a Role which then establishes which privileges are enforced.

I understand OpenBMC systems use Redfish and have multiple Ethernet ports (aka Ethernet jacks) which are connected to very-different places. Each of these ports can be wired to a different access channel. Typical examples:
1. Port connected to a private management network (the canonical setup).
2. Port connected only to the host system, for example.
3. Port normally unused available to a service agent who has the privilege of physical access (and a laptop to plug in).

Further, these access channels play a role in establishing security domains. For example:
A. The BMC admin normally accesses the BMC via its management network. If needed, the admin can use their access the host platform to access to the BMC.
B. The BMC admin normally accesses the BMC via its host platform. For example, the admin first gains root access to the host computer and then accesses the BMC. (This use case is typical for a standalone computer, but incompatible with rented bare-metal servers.)

A mechanism is desired to restrict access to the Redfish APIs based on the access channel. Questions:

1. Do we need to control access to the channel itself? Like the function provided by the ManagerNetworkProtocol?
2. Do we want to restrict which users can access via each channel? Like OpenBMC's "group roles" described here?: github.com/openbmc/docs/blob/master/architecture/user_management.md#supported-group-roles
3. Do we want to be able to assign a different Redfish Role to users based on which access channel they used to access the BMC?

I think we should start with a problem statement. What problem are we trying to solve? Is there a specific use case or requirement?

I've added a topic for this issue to the 2020-02-19 agenda for the OpenBMC security working group meeting ... to see if we can make progress defining requirements. docs.google.com/document/d/1b7x9BaxsfcukQDqbvZsU2ehMq4xoJRQvLxxsDUWmAOI

The OpenBMC security working group discussed this on 2020-02-19 (minutes: docs.google.com/document/d/1b7x9BaxsfcukQDqbvZsU2ehMq4xoJRQvLxxsDUWmAOI). There was not much active discussion, but one example was documented:
> Idea: expose the list of channels within OpenBMC, and allow Account-Channel associations. For example, an interface to allow “admin2” to access the BMC only from “eth0” or “eth1” but not “eth2”.